RFC: True MVC blocks using DTO's #1008
Conversation
|
|
||
| class Icon_Grid_Controller extends Abstract_Controller { | ||
|
|
||
| public const ATTRS = 'attrs'; |
There was a problem hiding this comment.
Look at everything that got removed from this controller! 😍
|
|
||
| class Icon_Grid_Model extends Block_Model { | ||
|
|
||
| public string $title = ''; |
There was a problem hiding this comment.
These class properties should match the field names you defined in your Block_Config class, then they will get auto populated with the data.
Add a new field to the Block_Config, add it here and then it's automatically available in the controller's $this->model instance.
No more adding defines, controller properties or defaults, that's all done here now!
| 'category' => 'common', // core categories: common, formatting, layout, widgets, embed | ||
| 'supports' => [ | ||
| 'align' => false, | ||
| 'anchor' => true, | ||
| 'html' => false, | ||
| ], | ||
| 'model' => Icon_Grid_Model::class, | ||
| 'view' => 'icon_grid', | ||
| 'controller' => Icon_Grid_Controller::class, |
There was a problem hiding this comment.
Note: this is where you'd define your block's Model, View and Controller. Of course, we'd update the block generator to do this automatically.
I'm open to better ways for this as it's ideal, but it will work and provide flexibility if absolutely required.
|
|
||
| protected function required(): array { | ||
| return [ | ||
| self::CLASSES => [ |
There was a problem hiding this comment.
Still need to implement a system that does this.
| * @throws \DI\DependencyException | ||
| * @throws \DI\NotFoundException | ||
| */ | ||
| public function render_template( array $block, string $content, bool $is_preview, int $post_id, ?WP_Block $WP_block, array $context = [] ): void { |
There was a problem hiding this comment.
This is where the model and controller are instantiated because it's the only time the data we need is available.
All the magic happens here, fields get populated etc...this still needs some tweaks and clean up but it shows it will work and once I implement and interface for it, we can even replace it on a per project basis if the situation calls for it.
We can fine tune control of what gets passed to the view as well which was a thing that is badly missing from get_template_part(), but standard blocks really just need the controller.
|
Thanks for mocking this up, @defunctl . The only concern/question I have relates to being able to use a block template/view with data other than an ACF block's registered fields. For example, We often end up with patterns where a Hero Block and a Post Subheader use the same data, layout options, etc but the latter's data source is ACF fields defined for a post type rather than via a block. Can you help me understand how we might accomplish that with this architecture? (Ideally not having to duplicate the template file, Controller classes, CSS/JS, etc.) |
|
@dpellenwood can definitely look into that, can you point me to code where we're doing that now so I can have a look? |
Sure thing. Harvard Public Health has a recent example: Hero Block & Post "Subheader" built by calling the Hero Block template and setting up the necessary data via Post meta fields. |
Awesome, I'll check it out this eve and get back to you. |
|
@dpellenwood see the updated code pushes. I converted the Hero block into this MVC Field Model system and am now using it in the Single Controller/View, similar to your code example. It still needs work, but definitely shows the basic idea once it's been polished up some. Screenshot of the hero block being used inside the Single Controller/View:
|
Lovely. Makes total sense to me. Thanks for demoing it! |
|
I know this PR is still a WIP but I am going to brain dump some thoughts after a scan of everything:
|
What does this do/fix?
A proof of concept for a single block to show the possibility of true MVC blocks.
This:
TODO
QA
Screenshots/video:
Icon Grid Edit Screen:
Icon Grid Frontend:
Tests
Does this have tests?